メインコンテンツまでスキップ

AKSとFluxCDによるGitOps

GitOpsは、Gitリポジトリを「信頼できる唯一の情報源（Single Source of Truth）」として扱い、インフラストラクチャやアプリケーションの構成を管理・デプロイする手法です。本ドキュメントでは、Azure Kubernetes Service (AKS) と FluxCD を組み合わせたGitOpsの実践方法とベストプラクティスについて解説します。

GitOpsとは​

GitOpsは、DevOpsのベストプラクティスをインフラストラクチャの自動化に適用したものです。

主な特徴​

  1. 宣言的定義: システム全体の状態をGitで宣言的に管理（YAMLなど）
  2. バージョン管理: 変更履歴、レビュー、ロールバックがGitの機能で完結
  3. 自動適用: Gitの状態とクラスタの状態を自動的に同期
  4. 継続的調整: ドリフト（設定の乖離）を検知し、あるべき状態に修正

FluxCDの概要​

FluxCDは、CNCF（Cloud Native Computing Foundation）のGraduatedプロジェクトであり、Kubernetesのためのオープンで拡張可能な継続的デリバリーソリューションです。

FluxCDのコンポーネント​

  • Source Controller: GitやHelmリポジトリなどのソースからアーティファクトを取得
  • Kustomize Controller: KustomizeやプレーンなYAMLを適用
  • Helm Controller: Helmチャートのリリースを管理
  • Notification Controller: イベント通知（Slack, Teamsなど）を処理

Kustomizeの活用​

Kustomizeは、Kubernetesマニフェスト（YAMLファイル）をカスタマイズするための設定管理ツールです。Helmのようなテンプレートエンジンとは異なり、元のYAMLファイルを変更せずに、別のYAMLファイル（パッチ）を重ね合わせることで設定を変更します。

BaseとOverlays​

Kustomize管理における重要な概念が Base と Overlays です。

  • Base: アプリケーションの基本となるマニフェスト群です。すべての環境で共通する設定（DeploymentやServiceの定義など）を記述します。
  • Overlays: Baseを参照し、環境ごとの差分（パッチ）を定義します。例えば、開発環境（Dev）と本番環境（Prod）で異なるレプリカ数やリソース制限、環境変数を設定する場合に使用します。

この仕組みにより、環境ごとにYAMLファイルをコピー&ペーストする必要がなくなり、設定の重複排除と保守性の向上が図れます。

アーキテクチャ​

AKS上でFluxCDを使用したGitOpsの基本的なアーキテクチャは以下の通りです。

処理の流れ​

  1. 開発者がアプリケーションコードを修正し、App Repositoryにプッシュ。
  2. CIパイプラインが走り、テスト、ビルド、コンテナイメージの作成を行う。
  3. イメージをAzure Container Registry (ACR) にプッシュ。
  4. CIパイプラインがConfig Repositoryのマニフェスト（Deploymentのimage tagなど）を更新。
  5. AKS内のFluxCDがConfig Repositoryの変更を検知（または定期ポーリング）。
  6. FluxCDが新しい設定をクラスタに適用（Reconcile）。
  7. Kubernetesが新しいイメージをACRからプルしてPodを更新。

AKSでのFluxCDセットアップ​

AKSでは、クラスタ拡張機能（Cluster Extension）としてFluxを簡単に導入できます。

Azure CLIによるインストール​

# 必要な拡張機能プロバイダーの登録
az provider register --namespace Microsoft.Kubernetes
az provider register --namespace Microsoft.ContainerService
az provider register --namespace Microsoft.KubernetesConfiguration

# Flux拡張機能のインストール
az k8s-extension create \
    --name flux \
    --extension-type microsoft.flux \
    --scope cluster \
    --resource-group <ResourceGroup> \
    --cluster-name <AKSClusterName> \
    --cluster-type managedClusters

ディレクトリ構成のベストプラクティス​

GitOpsリポジトリ（Config Repository）の構成は、スケーラビリティと管理のしやすさに直結します。

推奨構成例（マルチテナント/マルチ環境）​

├── apps/                   # アプリケーションごとのベース設定
│   ├── base/
│   │   ├── my-app/
│   │   │   ├── deployment.yaml
│   │   │   ├── service.yaml
│   │   │   └── kustomization.yaml
│   └── overlays/           # 環境ごとの差分
│       ├── dev/
│       ├── staging/
│       └── prod/
├── infrastructure/         # インフラ系コンポーネント（Ingress, Cert-Manager等）
│   ├── base/
│   └── overlays/
└── clusters/               # クラスタごとのFlux設定
    ├── dev-cluster/
    │   ├── flux-system/
    │   ├── apps.yaml       # appsディレクトリへの参照
    │   └── infra.yaml      # infrastructureディレクトリへの参照
    └── prod-cluster/

ベストプラクティス​

1. アプリケーションコードと設定の分離​

アプリケーションのソースコードリポジトリと、Kubernetesマニフェストを管理する設定リポジトリは分けることを推奨します。これにより、CI（ビルド）とCD（デプロイ）の責務が明確になり、無限ループ（ビルド→デプロイ→コミット→ビルド...）を防げます。

2. Kustomizeの活用​

環境（Dev, Staging, Prod）ごとの設定差分を管理するために、Kustomizeを使用します。重複コードを減らし、ベース設定を共有することで保守性が向上します。

3. シークレット管理​

Gitリポジトリに生パスワードやAPIキーを含めてはいけません。以下のいずれかの方法を検討します。

  • Sealed Secrets: 公開鍵で暗号化し、Gitにコミット。クラスタ内のコントローラーが秘密鍵で復号。
  • Azure Key Vault Provider for Secrets Store CSI Driver: Azure Key Vaultから直接シークレットをマウント。

4. ドリフト検知と通知​

Fluxの通知機能を設定し、同期の失敗やドリフトの発生をSlackやMicrosoft Teamsに通知するようにします。これにより、問題に早期に気づくことができます。

5. イメージ更新の自動化​

FluxのImage Automation Controllerを使用すると、ACRに新しいタグがプッシュされた際に、自動的にGitリポジトリのマニフェストを書き換えてコミットすることができます。これにより、CIパイプラインからGitへの書き込み処理を省略できます。

まとめ​

AKSとFluxCDを組み合わせることで、堅牢で監査可能なデリバリーパイプラインを構築できます。Gitを中心とすることで、オペレーションの透明性が高まり、クラスタの状態管理が容易になります。